Approved. I use something similar in my Java (Gradle) projects. It would be slick if this information were accessible from Lisp core - but not as part of this PR.

Yes, making it visible from Lisp would be good. I'd probably change the format of the version string too. It's not trivial to create a new string in Lisp space from the C side, anything that does that tends to overwrite the characters of an existing string when the variable gets passed down to a subr. The BCPL username is a special case, where there are 32 words allocated in the interface page at a known offset, and we just fill it in and then adjust the layout to account for byte swapping.

If we cheat by making the version a "semantic versioning" triple of integers, would it be easier? For example, version 1.2.3 would be represented as the three numbers (unsigned bytes, really) 1, 2, and 3.

Doesn't help too much with a Git commit hash. There is already a Maiko build date, and version numbers Lisp, "microcode", and BCPL --

        DLword    lversion;  // access via (LISPVERSION)
        DLword    minrversion;
        DLword    minbversion;
        DLword    rversion; // access via (MICROCODEVERSION)
        DLword    bversion; // access via (BCPLVERSION)

The MDate (the Maiko build date) is used to set the rversion as (MDate - 561150000) / (60 * 60 * 24), it's converting it to number of whole days since 12:00 13-Oct-87 -- Takeshi's birthday.

And, as the comment says in ldsout.c --

The sysout's ifpage.lversion must be >= LVERSION, and
the sysout's ifpage.minbversion must be <= MINBVERSION

Where the LVERSION and MINBVERSION constants track each other in the Maiko code with values of 15000, 20000, 20100, 21000, 30000, 35000, and 35010, but the ifpage.lversion is currently 39424 - the only place that gets set is by DUMPINITPAGES called under MAKEINIT if versions are passed to it. I would love to see the MAKEINIT dance written down. 39424 seems to come from internal/loadups/MAKEINIT. There was code in the old PARC-INIT which was setting up the local patch directories, and when passed "Medley" as the release name used 39424 to distinguish between "Medley" (it seems 39424 represented Medley 1.1) and "Medley1.15" (any other LVersion). I guess 39424 never got updated with newer Medley versions, but we set up the site init files to do the right thing.

True, git revision hashes have to be strings to be useful.

The rest of the explanation is great stuff and should be included in Maiko documentation , if it's not already.